home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-tn3270e-practices-00.txt < prev    next >
Text File  |  1993-08-18  |  20KB  |  526 lines
  1.  
  2.  
  3.  
  4. TN3270 Enhancements Working Group                           Jon Penner
  5. Internet Draft                                             August 1993
  6.  
  7.                         TN3270 Current Practices
  8.  
  9.  
  10. Status of this Memo
  11.  
  12.    This document is an Internet Draft.  Internet Drafts are working
  13.    documents of the Internet Engineering Task Force (IETF), its Areas,
  14.    and its Working Groups.  Note that other groups may also distribute
  15.    working documents as Internet Drafts.
  16.  
  17.    Internet Drafts are draft documents valid for a maximum of six
  18.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  19.    other documents at any time.  It is not appropriate to use Internet
  20.    Drafts as reference material or to cite them other than as a
  21.    "working draft" or "work in progress."
  22.  
  23.    Please check the 1id-abstracts.txt listing contained in the
  24.    internet-drafts Shadow Directories on ds.internic.net,
  25.    nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
  26.    current status of any Internet Draft.
  27.  
  28. Abstract
  29.  
  30.    This document describes the existing implementation of transferring
  31.    3270 display terminal data using currently available telnet
  32.    capabilities.   The name traditionally associated with this
  33.    implementation is TN3270.
  34.  
  35.    Information is provided to aid in the implementation of TN3270
  36.    servers as well as client terminal emulators.
  37.  
  38.    The following areas pertaining to TN3270 implementations are
  39.    covered in this document:
  40.  
  41.    1. the telnet options negotiated to transition from a NVT ASCII
  42.    state to a TN3270 state ready to process incoming 3270 data stream
  43.    commands
  44.  
  45.    2. the method for sending and receiving 3270 data
  46.  
  47.    3. the method of handling some special keys known as SYSREQ and
  48.    ATTN using current available telnet commands.
  49.  
  50.    4. the events that will transition a TN3270 session back to an NVT
  51.    session
  52.  
  53.  
  54. Motivation
  55.  
  56.    3270 display terminal data differs from traditional display terminal
  57.    data in that it is block mode and uses EBCDIC instead of ASCII
  58.    character representation. These two differences are the primary
  59.  
  60. J. Penner                Expires February 1994                [Page 1]
  61.  
  62. TN3270 Enhancements Working Group                           Jon Penner
  63. Internet Draft                                             August 1993
  64.  
  65.    reason for the differentiation of TN3270 from standard Telnet in
  66.    this document.
  67.  
  68.  
  69. Background
  70.  
  71.    Existing proprietary IBM networks are not easily integrated with
  72.    the increasing number of multi-platform networking environments,
  73.    specifically TCP/IP. These proprietary IBM networks are referred to
  74.    as SNA (Systems Network Architecture) in this document. To address
  75.    this issue, several vendors have introduced telnet servers that
  76.    provide a TCP/IP users a connection to existing IBM mainframes by
  77.    supporting display terminal emulation using a subset of the existing
  78.    telnet protocol. IBM now also offers host based tn3270 support over
  79.    TCP/IP.
  80.  
  81.    IBM terminals are generically referred to as 3270's which
  82.    includes a broad range of terminals and devices, not all of which
  83.    actually begin with the numbers 327x.
  84.  
  85.    3270 terminals in the IBM SNA network environment have 2 parallel
  86.    sessions with the host computer. One is used for communicating with
  87.    the host application, the other is used for communicating with the
  88.    network control program that links the terminal with the
  89.    appropriate host computer.  For the purposes of TN3270, this
  90.    distinction is not apparent or relevant since there is actually
  91.    only a single telnet session with the host computer or server.  On
  92.    an IBM SNA network, the 3270 terminal has a special key that toggles
  93.    between the two sessions (SYSREQ).  A brief discussion on how
  94.    some telnet servers deal with this is included.
  95.  
  96.    In an SNA environment, a client session is identified by a Logical
  97.    Unit (LU) name.  In a non-SNA environment, there is not a LU name
  98.    associated with a client session.  The closest thing to a LU name
  99.    in the TN3270 environment is the client's IP address.  Although some
  100.    telnet servers are connected to the host using SNA, tn3270 clients
  101.    using these servers have no defined way to determine the LU name
  102.    associated with the session.
  103.  
  104.    Currently, support for 3270 terminal emulation over Telnet is
  105.    accomplished by the de facto standard of negotiating three separate
  106.    Telnet Options - Terminal-Type [2], Binary Transmission [3], and
  107.    End of Record [4].  This negotiation and the resulting data flow will
  108.    be described below.
  109.  
  110.    RFC 1041 [1] attempted to standardize the method of negotiating
  111.    3270 terminal support by defining the 3270 Regime Telnet Option.
  112.    Historically, very few developers and vendors ever implemented
  113.    RFC 1041.
  114.  
  115.    All references in this document to the 3270 datastream, SNA versus
  116.    non-SNA operation, 3270 datastream commands, orders, structured
  117.  
  118. J. Penner                Expires February 1994                [Page 2]
  119.  
  120. TN3270 Enhancements Working Group                           Jon Penner
  121. Internet Draft                                             August 1993
  122.  
  123.    fields and the like rely on [6].
  124.  
  125.    References to SNA Request and Response Units rely on [7].
  126.  
  127.    TN3270 does not support typical SNA responses and is classified as a
  128.    non-SNA protocol.  A TN3270 emulator is not aware or concerned about
  129.    how the telnet server is connected to a 3270 host application.
  130.    Current telnet server implementations are either 3270 host based or
  131.    connected to the host using the SNA protocol.
  132.  
  133.    NOTE: Except where otherwise stated, this document does not
  134.    distinguish between telnet servers that represent SNA devices and
  135.    those that represent non-SNA 3270 devices.
  136.  
  137.    Some typical "SNA" functions such as the SYSREQ
  138.    and ATTN keys have been mapped to existing telnet function codes
  139.    and are supported by some telnet server implementations.
  140.  
  141.    There are several shortcomings in current tn3270 implementations;
  142.    among them are the following:
  143.  
  144.     - It provides no capability for Telnet clients to emulate the 328x
  145.       class of printers.
  146.  
  147.     - There is no mechanism by which a Telnet client can request that
  148.       a connection be associated with a given 3270 device-name.  This
  149.       can be of importance when a terminal session is being
  150.       established, since many host applications behave differently
  151.       depending on the network name of the terminal.  In the case of
  152.       printer emulation, this capability is an absolute necessity
  153.       because a large number of host applications have some method of
  154.       pre-defining printer destinations.
  155.  
  156.     - The 3270 ATTN and SYSREQ keys are not universally supported.
  157.  
  158.     - There is no support for the SNA positive/negative response
  159.       process. All data that is sent is assumed to either be handled
  160.       or ignored.
  161.       A negative response indicates some sort of error at the client
  162.       while processing the previously received data; this could be
  163.       caused by the host application building a 3270 datastream that
  164.       contains an invalid command, or by a mechanical error at the
  165.       client side, among other things.
  166.       Positive responses indicate processing of the previously received
  167.       data has completed.
  168.  
  169.     - There is no mechanism by which the client can access the SNA
  170.       BIND information.  The BIND image in a SNA environment
  171.       contains a detailed description of the session between the
  172.       telnet server and the host application.
  173.  
  174.     - The connection negotiation does not make it clear whether clients
  175.  
  176. J. Penner                Expires February 1994                [Page 3]
  177.  
  178. TN3270 Enhancements Working Group                           Jon Penner
  179. Internet Draft                                             August 1993
  180.  
  181.       should support 3270 structured fields.
  182.  
  183.    These and other issues are addressed by the Internet-Draft [?]
  184.    written by Bill Kelly
  185.  
  186.  
  187. Command Names and Codes
  188.  
  189.    TN3270 makes use of existing Telnet commands and codes and does
  190.    not define any new commands.
  191.  
  192.        BINARY            0
  193.        TERMINAL-TYPE    24
  194.        EOR              25
  195.  
  196.    Additional commands may be used during a TN3270 session and are
  197.    interpreted as per their respective RFCs. Examples of this are
  198.    3270-REGIME, SUPPRESS-GO-AHEAD, and TM.
  199.  
  200.  
  201.  
  202. Command Meanings
  203.  
  204.    See respective RFCs.
  205.  
  206.  
  207. Connection Negotiation
  208.  
  209.    The following example shows a TN3270-capable server and a
  210.    tn3270 client establishing a connection:
  211.  
  212.  
  213.    The TCP/IP port generally used to connect with is 23 (Telnet).
  214.  
  215.    At any place before and during the tn3270 connection negotiation
  216.    process, other telnet commands and data may be transferred and
  217.    will be interpreted under the existing telnet state. Some existing
  218.    tn3270 servers start a client connection using an NVT telnet
  219.    dialog to establish parameters needed to complete the tn3270
  220.    connection to the desired host.
  221.  
  222.    The order of negotiating terminal type, EOR and BINARY is not
  223.    significant, this example shows a typical tn3270 connection.
  224.  
  225.       Server:  IAC DO TERMINAL-TYPE
  226.  
  227.       Client:  IAC WILL TERMINAL-TYPE
  228.  
  229.       Server:  IAC SB TERMINAL-TYPE SEND IAC SE
  230.  
  231.       Client:  IAC SB TERMINAL-TYPE IS <terminal type>IAC SE
  232.  
  233.  
  234. J. Penner                Expires February 1994                [Page 4]
  235.  
  236. TN3270 Enhancements Working Group                           Jon Penner
  237. Internet Draft                                             August 1993
  238.  
  239.        where <terminal type> is a string consisting of terminal model,
  240.      type and support of enhanced attribute bytes; and example is
  241.      IBM-3278-2.  The acceptable values are listed in RFC 1340,
  242.      Assigned Numbers [5].  Other values are in use that do not exist
  243.      in [5].
  244.    
  245.      The -2 following 3278 designates the alternate screen size.
  246.      3270 terminals have the ablity to switch between the
  247.      standard (24x80) screen size and an alternate screen size.
  248.      Model -2 is 24x80 which is the same as the standard size.
  249.      Model -3 is 32x80, model -4 is 43x80 and model -5 is 27x132.
  250.  
  251.      Appending the two character string "-E" to the end of the
  252.      terminal type signifies that the terminal is capable of handling
  253.      3270 extended data stream. This is interpreted to mean that the
  254.      terminal is able to handle structured fields, which are
  255.      described below.  Some telnet server implementations also
  256.      interpret this to mean that the terminal is capable of handling
  257.      extended attributes (highlighting, field validation, character
  258.      set, outlining, etc.) [6].
  259.  
  260.      The 3279 series of terminals is capable of extended attributes
  261.      while the 3278 series is not.
  262.  
  263.       Server:  IAC DO EOR IAC WILL EOR
  264.       Client:  IAC WILL EOR IAC DO EOR
  265.       Server:  IAC DO BINARY IAC WILL BINARY
  266.       Client:  IAC WILL BINARY IAC DO BINARY
  267.       Server:  <3270 data stream>
  268.       Client:  <3270 data stream>
  269.            .            .
  270.            .            .
  271.  
  272.    To terminate the connection the socket is closed by one of
  273.    the session partners. Typically, when the user logs off of the
  274.    host, the telnet server closes the connection.
  275.  
  276.    If the telnet server wishes to go back to NVT mode, it may issue
  277.    the following commands:
  278.  
  279.        Server:  IAC WONT BINARY
  280.        Client:  IAC DONT BINARY
  281.  
  282.            or
  283.  
  284.        Server:  IAC WONT EOR
  285.        Client:  IAC DONT EOR
  286.  
  287.    Either one of the above two cases causes the connection to not
  288.    satisfy the requirements for a valid TN3270 session. The telnet
  289.    client should then process data from the server as though it
  290.    were NVT ASCII data.
  291.  
  292. J. Penner                Expires February 1994                [Page 5]
  293.  
  294. TN3270 Enhancements Working Group                           Jon Penner
  295. Internet Draft                                             August 1993
  296.  
  297.  
  298. Handling 3270 data
  299.  
  300.    The 3270 data stream consists of a command and its associated data.
  301.    Commands include but are not limited to erase screen, erase and write
  302.    to screen and read current screen; see [6] for a complete description
  303.    of 3270 commands and parameters.
  304.  
  305.    The reason for negotiating the EOR telnet option [4] is to provide a
  306.    method for separating these commands since no length information is
  307.    specified. 3270 commands are interpreted by the telnet client in
  308.    their entirety.  Each 3270 command and possible data is terminated
  309.    with the IAC EOR sequence.
  310.  
  311.    The Binary option [3] is also required since 3270 data may contain
  312.    the FF (hexadecimal) or IAC character. When this character is
  313.    encountered during a tn3270 connection it is handled as per the
  314.    Binary RFC [3].
  315.  
  316. 3270 Structured Fields
  317.  
  318.    3270 structured fields provide a much wider range of features than
  319.    "old-style" 3270 data, such as support for graphics, partitions and
  320.    IPDS printer datastreams. A structured field is a 3270 data type
  321.    that allows non 3270 data to be embedded within 3270 data. Briefly,
  322.    a structured field consists of the structured field command followed
  323.    by one or more data blocks. Each data block has a length and a
  324.    structured field identifier, followed optionally by additional data.
  325.  
  326.    Not every TN3270 client can be expected to support all structured
  327.    field functions.   There must be a  mechanism by which those clients
  328.    that are capable of supporting some or all structured field
  329.    functions can indicate their wishes. This is typically done by
  330.    adding "-E" to the end of the terminal type string. That is, when the
  331.    terminal identifies itself as being able to handle extended
  332.    attributes, it also is capable of being able to send and receive
  333.    structured fields.
  334.  
  335.    The design of 3270 structured fields provides a convenient means to
  336.    convey the level of support (including no support) for the various
  337.    structured field functions.  This mechanism is the Read Partition
  338.    Query command, which is sent from the host application to the
  339.    client.  The client responds with a Query Reply, listing which,
  340.    if any, structured field functions it supports.
  341.  
  342.    A TN3270 client that supports structured fields will
  343.    respond to a Read Partition Query command with the appropriate reply.
  344.    The sequence of events of when a client receives a Read Partition
  345.    Query and it does not support structured fields is left up to the
  346.    client implementation.  Typically clients can identify at least this
  347.    structured field and reply with a null set.
  348.  
  349.  
  350. J. Penner                Expires February 1994                [Page 6]
  351.  
  352. TN3270 Enhancements Working Group                           Jon Penner
  353. Internet Draft                                             August 1993
  354.  
  355.  
  356. Implementation Rules
  357.  
  358.    All commands and parameters are governed by their respective RFCs
  359.  
  360.  
  361. The 3270 ATTN (Attention) Key
  362.  
  363.    The 3270 ATTN key is interpreted by many host applications in an
  364.    SNA environment as an indication that the user wishes to interrupt
  365.    the execution of the current process.  A majority of the telnet
  366.    servers currently accept the telnet IAC BREAK (code 243) sequence to
  367.    signal this event.
  368.  
  369.    Use of this key requires two things:
  370.  
  371.     - TN3270 clients should provide as part of their keyboard
  372.       mapping a single key or a combination of keys that map to
  373.       the 3270 ATTN key.  When the user presses this key(s), the
  374.       client should transmit a Telnet BREAK command to the server.
  375.  
  376.     - TN3270 servers should translate the BREAK command received from
  377.       a TN3270 client into the appropriate form and pass it along
  378.       to the host application as an ATTN key.  In other words, the
  379.       server representing an SLU in an SNA session should send
  380.       a SIGNAL RU to the host application.
  381.  
  382.    The ATTN key is not supported in a non-SNA environment; therefore,
  383.    a TN3270 server representing non-SNA 3270 devices should ignore
  384.    any Telnet BREAK commands it receives from a client.
  385.  
  386. The 3270 SYSREQ Key
  387.  
  388.    The 3270 SYSREQ key is useful in an environment where the
  389.    telnet server is attached to the host using SNA. The SYSREQ key
  390.    is useful in this environment when the host application becomes
  391.    locked and the user wishes to terminate the session without
  392.    closing the Telnet connection.
  393.  
  394.    The Telnet Interrupt Process (IP) command is interpreted by some
  395.    telnet servers as a SYSREQ key. Other servers recognize the 3270
  396.    Test Request key as a SYSREQ key.  In an SNA environment, pressing
  397.    this key toggles the terminal between the host application session
  398.    and the network control program session.  Usually the user
  399.    will enter LOGOFF once this key has been pressed to terminate
  400.    the application session and then select a new host to connect to.
  401.    Sometimes, if SYSREQ is pressed again, the host application will
  402.    become unlocked and normal activities may then proceed.
  403.  
  404.    It is entirely up to the telnet server to interpret this command and
  405.    send the appropriate commands to the host as well as format the
  406.    resulting host data for display on the telnet client. The data
  407.  
  408. J. Penner                Expires February 1994                [Page 7]
  409.  
  410. TN3270 Enhancements Working Group                           Jon Penner
  411. Internet Draft                                             August 1993
  412.  
  413.    format during the network control program session is in a slightly
  414.    different format than normal 3270 data. Since the telnet server
  415.    has no way to pass this data directly to the telnet client, it must
  416.    either handle it entirely and ignore SYSREQ events or convert it to
  417.    3270  data to present to the client.  There is no restriction that
  418.    prevents the server from negotiating out of the TN3270 state to
  419.    NVT to present this data.
  420.  
  421.    In order to implement SYSREQ key support, TN3270
  422.    clients should  provide a key (or combination of keys) that is
  423.    identified as mapping to the 3270 SYSREQ key.  When the user presses
  424.    this key(s), the client should either transmit a Telnet IP command
  425.    or Test Request key to the server, depending on the server
  426.    implementation.
  427.  
  428.    TN3270 servers representing non-SNA 3270 terminals may ignore any
  429.    Telnet IP commands or Test Request keys they receive from a client.
  430.  
  431.  
  432. References
  433.  
  434. [1] Rekhter, J., "Telnet 3270 Regime Option", RFC 1041, IBM
  435.     Corporation, January 1988.
  436.  
  437. [2] VanBokkelen, J., "Telnet Terminal-Type Option", RFC 1091,
  438.     FTP Software, Inc., February 1989.
  439.  
  440. [3] Postel, J., and J. Reynolds, "Telnet Binary Transmission",
  441.     RFC 856, USC/Information Sciences Institute, May 1983.
  442.  
  443. [4] Postel, J., "Telnet End of Record Option", RFC 885, USC/
  444.     Information Sciences Institute, December 1983.
  445.  
  446. [5] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1340,
  447.     USC/Information Sciences Institute, July 1992.
  448.  
  449. [6] "3270 Information Display System - Data Stream Programmer's
  450.     Reference", publication number GA23-0059, IBM Corporation.
  451.  
  452. [7] "Systems Network Architecture - Formats",
  453.     publication number GA27-3136, IBM Corporation.
  454.  
  455.  
  456. Author's Note
  457.  
  458.    Portions of this document were drawn from the following sources:
  459.  
  460.     - A White Paper written by Owen Reddecliffe, WRQ Corporation,
  461.       October 1991.
  462.  
  463.     - Experimental work on the part of Cleve Graves and Michelle
  464.       Angel, OpenConnect Systems, 1992 - 1993.
  465.  
  466. J. Penner                Expires February 1994                [Page 8]
  467.  
  468. TN3270 Enhancements Working Group                           Jon Penner
  469. Internet Draft                                             August 1993
  470.  
  471.  
  472.     - Discussions at the March 1993 IETF meeting.
  473.  
  474.     - Discussions on the "TN3270E" list, Spring 1993.
  475.  
  476.     - An Internet-draft written by Bill Kelly, Auburn University,
  477.       July, 1993
  478.  
  479.  
  480. Author's Address
  481.  
  482.    Jon Penner
  483.    DCA, Inc.
  484.    2800 Oakmont Drive
  485.    Austin, TX 78664
  486.  
  487.    Phone: (512) 244-3871
  488.  
  489.    Email: jjp@bscs.uucp
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506.  
  507.  
  508.  
  509.  
  510.  
  511.  
  512.  
  513.  
  514.  
  515.  
  516.  
  517.  
  518.  
  519.  
  520.  
  521.  
  522.  
  523.  
  524. J. Penner                Expires February 1994                [Page 9]
  525.  
  526.